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transaction processing system. The new interface architec- 
ture isolate attributes of the requesters and the communica- 
tion programs into individual software components so that 
all software code associated with each requester type is 
included within a corresponding requester software module, 
and all software code associated with each communications 
program is included within a corresponding communica- 
tions software module. Each new requester type added 
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550- 



typedeF struct 



{ 



■552 



•554 



■556 



int argc; 
char "argv. 

'pGate_in_dots; 

#iFdeF WIN32 ^-558 
DWORD dwGate_in_data_len: 

#else . 
long dwGate_in_data_len; 

#endiF 

ReqVars pVars: 

Cookielnf o 'pCookie 
#iFdeF WIN32 

BOOL bWr_Cookies: 

#else 

int bWr_Ccokies: 

#endiF ^ 

in t Resp-Control. _^570 

char Resp_ContentTypelM^ 572 
•pTmp_Userl_ ^^574 
'pTmpJJser^, - 
'pWr_CookieBuF. ^-^/O 

Reserved[40]; 
) GatelnF o: 



■560 
--562 

^-564 

--566 

_--568 



1U. 
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typedeF struct 



{ 



) ReqV 



char 'pServer_ Soft wane. 
'pServer_NQme, 
'pServer_ Protocol, 
*pServer_ Port, 
'pRequest— Method, 
pPath_Info. 
'pPath— Translated, 
'pScript_Name. 
'pQuery_ String. 
'pRemate_ Host. 
'pRemote_Addr. 
'pAuth— Type. 
'pAuth—Userid— Password. 
'pRemote_ User. 
'pRemote_Ident. 
'pCon tent— Type. 
'pCon tent— Length. 
'pHttp— Accept. 
'pHttp— User —Agent. 
'plnternalData: 



eqVQrs 



/ — \ 



lu. 
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PROVIDING A MODULAR GATEWAY 
ARCHITECTURE WHICH ISOLATES 
ATTRIBUTES OF THE CLIENT AND 
SERVER SYSTEMS INTO INDEPENDENT 

COMPONENTS s 

CROSS REFERENCE TO CO-PENDING 
APPLICATIONS 

The present application is related to U.S. patent applica- 
tion Ser. No. 08/622,099, filed Mar. 26, 1996 entitled 10 
"Transaction Service Independent HTTP Server-to Transac- 
tion Gateway", now U.S. Pat. No. 5,754,772, U.S. patent 
application Ser. No. 09/164,759, filed Oct. 1, 1998, entitled 
"A Common Gateway Which Allows Java Applets to Make 
Program Calls to OLTP Applications Executing on an Enter- 15 
prise Server" still pending, and U.S. patent application Ser. 
No. 09/164,932, filed Oct. 1, 1998 entitled "A Multi-Client, 
User-Customized DCOM Gateway for an OLTP Enterprise 
Server Application" still pending, all assigned to the 
assignee of the present invention and incorporated herein by 20 
reference. 

BACKGROUND OF THE INVENTION 

Field of the Invention 25 

The present invention relates generally to interfaces 
which interface a variety of requester types coupled to a 
server with a variety of communications programs coupled 
to an on-line transaction processing system, and more 
particularly, to such interfaces which isolate attributes of the 30 
requesters and the communications programs into individual 
software components. 2. Description of the Prior Art 

The methods by which companies conduct business with 
their customers are undergoing fundamental changes, due in 35 
part to world wide web technology This same technology 
which makes a company accessible to customers around the 
world, may also be used on internal company networks, to 
complete operational and administrative tasks. 

One of the technologies within the world wide web is the ^ 
web browser. Web browsers are quickly becoming a defacto 
user interface standard to the world wide web because of 
their ability to interpret and display information having 
standard formats (e.g. HyperText Mark-Up Language 
(HTML), standard text GIF, etc.). Client software programs, 45 
typically referred to as web browsers (e.g. Mosaic, Lynx, 
etc.), execute on client systems and issue requests to server 
systems. Server systems typically execute HyperText Trans- 
port Protocol (HTTP) server programs, and process requests 
received from the web browsers. so 

Many businesses still have information maintained and 
managed by data base management systems such as DMS, 
RDMS, DB2, Oracle, Ingres, Sybase, Informix, and many 
others. Many of these database management systems are 
being utilized as resources within larger transaction process- 55 
ing systems. In view of this, businesses have begun to 
recognize and capitalize on the growing utility of web 
browsers to provide access to data stored within their 
database management systems. 

To provide the access, software gateways, also known as 60 
"middle ware", execute on the server systems in order to link 
the web browsers to the data base management systems. A 
gateway typically receives a user request and associated data 
from the web browser, and packages the data into a specific 
format, and forwards the request and data to the data base 65 
management system. The data base management system 
then processes the request, and sends the result back to the 
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gateway. The gateway may then provide the result to the 
requester in a specified format. 

Gateways must accommodate many different types of 
user requests, as web browsers typically utilize any number 
of software languages. One type of request may be an 
application on the web browser which is executing the Java 
programming language (e.g. a Java applet). This approach is 
described in U.S. patent application Ser. No. 09/164,759, 
entitled "A Common Gateway Which Allows Java Applets 
to Make Program Calls to OLTP Applications Executing on 
an Enterprise Server*' still pending, which has been incor- 
porated herein by reference. Another type of request may be 
an application running under the MicroSoft DCOM envi- 
ronment. This approach is described in U.S. patent applica- 
tion Sen No. 09/164,932 entitled "A Multi-client User- 
customized DCOM Gateway for an OLTP Enterprise Server 
Application" still pending, which has been incorporated 
herein by reference. Yet another type of requester is when 
the Web Browser provides requests in Hyper Text Markup 
Language (HTML) format. This approach is described in 
U.S. patent application Ser. No. 08/622,099 entitled "Trans- 
action Service Independent Http Server-to Transaction 
Gateway", now U.S. Pat. No. 5,754,772, which has been 
incorporated herein by reference. 

Each of the different types of requests described above 
require a specific gateway to be serviced. For example, a 
Java gateway must be provided to service requests from the 
Java applets. A DCOM gateway must be provided to service 
requests from applications running under the MicroSoft 
DCOM environment. And yet another gateway must be 
provided to support requests from the Web Browser in the 
HTML format. 

These various gateways must also support a wide variety 
of communications programs which are used to provide 
communications between the server systems and the data- 
base management systems. Each communication program 
has specific communications protocol requirements, thus 
requiring unique input and output formats. Examples of 
communications programs include Pathway (commercially 
available from the Unisys Corporation), HTP/ic 
(commercially available from the Unisys Corporation) and 
COMAPI. 

Thus gateways must accommodate many different types 
of requesters and a variety of communications programs. 
The gateway typically includes software code which accepts 
and processes a specific type of requester, which is inte- 
grated with the code to interface to the communications 
programs. For example, if the requester is the Java Applet, 
the gateway to support the Java Applet must support each 
type of communications program the Java Applet may 
access. Thus, for example, three Java gateways must be 
created if a Java Applet is to have access to three different 
communications programs such as Pathway, HTP/ic, and 
COMAPI. The same is true for DCOM and HTML request 
types. 

Thus, in prior art systems where each requester must 
access a number of communications programs, the required 
number of gateways resident on the server is equal to the 
number of requester types times the number of communi- 
cations programs to which access is required. Unfortunately, 
this approach requires a potentially large number of different 
types of gateways. And each time a new communications 
program is added, a new version of each gateway must be 
created. Since each new gateway requires customized inter- 
faces involving extensive rewriting of gateway software, 
this task can be prohibitively time consuming and expen- 
sive. 
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SUMMARY OF THE INVENTION 

The present invention overcomes the disadvantages found 
in the prior art by providing a new gateway architecture 
which reduces the number of software components required 
to interface a number of requesters with a number of 
communications programs. The new interface architecture 
isolates attributes of the requesters and communications 
programs into individual software components or modules, 
so that all software code associated with each requester type 
is included within a corresponding requester software 
module, and all software code associated with each com- 
munications program is included within a corresponding 
communications software module. Each requester software 
module can communicate with every communications soft- 
ware module through a standardized interface consisting of 
a number of program calls. 

The new gateway architecture reduces the amount of 
software code required to add a new requester or commu- 
nications program. Each new requester type added requires 
the addition of only one requester software module, and each 
new communications program added requires the addition of 
only one communications software module. This reduces the 
overall number of software modules required to interface the 
requesters to the communications programs to a number 
equal to the number of requesters plus the number of 
communications programs. 

In a preferred embodiment of the present invention, an 
interface is provided for linking each one of a number of 
requesters to each one of a number of communications 
programs. The interface comprises a number of first modules 
wherein each first module Corresponds to one of the number 
of requesters. The interface further comprises a number of 
second modules wherein one of a number of second modules 
corresponds to one of the number of communications pro- 
grams. The first modules interface with the second modules 
by passing a number of function calls between the first 
modules and the second modules, thus allowing requests to 
be submitted from the first module to the second module and 
results to be returned from the second module to the first 
module. 

One of the number of function calls is a first initialize 
function. The first initialize function is called once when a 
new requester is added. The first initialize function may be 
initiated by any means, such as an administrative program. 
The first initialize function initializes the first module and 
loads the corresponding second module corresponding to the 
desired communications program. The first initialize func- 
tion further makes a second initialize function call to ini- 
tialize the second module. The first initialize function may 
perform any number of functions within the scope of the 
present invention. These functions include establishing a 
communications session with the corresponding second 
module, opening an application program which is resident 
on the server, or assigning memory resources on the server. 

The second initialize function may also perform any 
number of functions within the scope of the present inven- 
tion. These functions include establishing a communications 
session with the desired communications program, opening 
an application program which is resident on the server, or 
assigning memory resources on the server. 

Another, function call is a first process request function. 
The first process request function is called by the first 
module to format the service request received from the 
requester for a second process request function call to the 
corresponding second module, in order to send the service 
request to the second module. The first process request 
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function also formats the result returned from the second 
module in response to the service request, and returns the 
result to the requester. 
The second process request function formats the service 

5 request received from the first module, so that the second 
module can send the service request to the desired commu- 
nications program. The second process request function also 
formats the result received from the communications pro- 
gram in response to the service request, so that the result can 

io be returned to the corresponding first module. 

Another function call is a first cleanup function. The first 
cleanup function is called once when a requester is stopped 
or removed. The first cleanup function may be initiated by 
any means, such as an administrative program. The first 

15 cleanup function terminates the first module and calls the 
second cleanup function. The second cleanup function ter- 
minates the second module. 

The effort to add new requesters or communications 
programs is greatly reduced over the prior art due to the use 

20 of program calls to create the standardized interface between 
the first and second modules. To add new requesters or 
communications programs, a minimal amount of new soft- 
ware code is required to create the new software modules, 
whether they are first modules to interface with new 

25 requesters, or second modules to interface with new com- 
munications programs, 

BRIEF DESCRIPTION OF THE DRAWINGS 
Other objects of the present invention and many of the 
30 attendant advantages of the present invention will be readily 
appreciated as the same becomes better understood by 
reference to the following detailed description when con- 
sidered in connection with the accompanying drawings, in 
which like reference numerals designate like parts through- 
35 out the figures thereof and wherein: 

FIG. 1 is a block diagram of the preferred data processing 
system in which the present invention is implemented; 

FIG. 2 is a block diagram of the preferred processing 
environment of the present invention; 
40 FIG. 3 is a block diagram showing the Microsoft NT 
processing environment in which the present invention is 
used; 

FIG. 4 is a block diagram showing a prior art gateway 
45 architecture. 

FIG. 5 is a block diagram illustrating prior art gateways 
incorporated within the data processing system of FIG. 1; 

FIG. 6 is a block diagram illustrating the gateway con- 
nector architecture of the present invention; 
50 FIG. 7 is a block diagram illustrating a preferred embodi- 
ment of the present invention showing the gateway connec- 
tor architecture incorporated within the data processing 
system of FIG. 1; 

FIG. 8 is a diagram showing the informational data 
55 structure used in the present invention; 

FIG. 9 is a diagram showing the data structure used to 
reference data variables provided by a web server; 

FIG. 10 is a diagram showing the data structure used to 
reference cookie data received by the server from the client 
60 browser, and 

FIGS. 11A, 11B and 11C are a flow diagram showing an 
exemplary method of the present invention. 

DETAILED DESCRIPTION OF THE 
65 PREFERRED EMBODIMENTS 

FIG. 1 is a block diagram of the preferred data processing 
system 8 in which the present invention may be imple- 
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mented It is recognized that the present invention may be client side and routes the requests to the correct place on the 

utilized in any data processing system wherein an interface server side, then passes a response from the server side back 

is required to interface a variety of requester types coupled to the client side. In the context of the present invention, 

to 7 server to a variety of communications programs WebTx "marries" a Microsoft client/server architecture 

coupled to an on-line transaction processing system. 5 (such as the NT node shown at 202) with a transactional 

- i r j . , nt _ n i lira iit v n f client/server architecture (such as the Unisys 2200 enterprise 

In the preferred embodiment, a plurality or . . ♦ >»nn\ 

PC/Workstations, designated as clients 10, 12, 14 and 16 are node shown at 200). 

coupledtoaserverl8viaanetwork20.TTienetwork20may The WebTx environment, as utilized in the present 

be an internal local area network, or may be the Internet. In invention, is comprised of several components, including a 

a preferred embodiment, each of the clients 10, 12, 14 and io monitor 201, a web server extensioc i 237 one or more 

16 is a web browser. The web browsers may be personal gateways 213, 217, 221 and 207 the WebViewC compiler 

computers or workstations having operating system soft- 290, a set of libraries 288, and other special purpose tools 

ware and application software. This software provides shown at 220. 

Graphical User Interface (GUI) and communications capa- WebTx Monitor 201 communicates with web server 

bilities to enable the client to communicate with server 15 extension 237 via interface 203, and gateway 207 via 

application 18 via network 20. In alternative embodiments, interface 209. Monitor 201 functions as the WebTx admin- 

the clients may be visual basic clients, or in general any GUI istrative tool. One function of Monitor 201 is to start and 

clicnt stop gateways 207, 213, 217, and 221, as required. Under a 

Workstation server system 50 may be any class of Unix environment, the WebTx _ momtormodule is known as 

machines which are capable of running a server application 20 WebMon, while under the Windows NT environment, the 

18 along with a distributed transaction processing system WebT* monitor module is known as WtxSvc. 

54 With the transaction processing system 54, a transaction WebTx web server extension 237 is a run-time extension 

is formatted on the workstation server system 50 and for- of web server 235 (such as Netscape FastTrack, Netscape 

warded to the enterprise server system 52 for processing. Enterprise, or Microsoft IIS). The function of web server 

In the preferred embodiment, the enterprise server system extension 237 is to intercept requests intended ^ WebTx 

52 is a Unisys 2200 series data processing system which 218, and instead route the requests to gateways 207 213 

includes a distributed transaction processing system 56. The 217, and 221. Web server extension 237 wiU also interpret 

distributed transaction processing system 56 encompasses the response from the gateways, and route tte reply_ Web 

the same functionality as a monolithic transaction process- server extension 237 * coupled to gateways 213, 217, 221 

1 system. But, in the preferred embodiment, the distrib- 30 and 207 via interfaces 211 215, 219 and 205, respecUvely. 

uted transaction processing system 56 is distributed to be Web server extension 237 ts connected to monitor 201 via 

compatible with L distributed transaction processing sys- interface 203, and HTML requester component 224 v» 

tern 54. Distributed transaction processing systems 54 and interface 228, and Java applet 226 via interface 234. 

56 utilize transaction manager software, such as the open/ 35 Gateways 213, 217, 221 and 207 perform tasks which are 

OLTP transaction manager software from Unisys, and utilize grouped into conceptual areas. Gateways 213, 217, 221 and 

user implemented open/OLTP services. Distributed transac- 207 receive requests from web server extension 237, or from 

tion processing system 54 is coupled to distributed transac- applications 212, and take whatever action is necessary to 

lion processing system 56 via network 58. Preferably, the fulfill the request. This typically involves transforming a 

network interface for network 58 is separate from the request (such as a URL from a web browser) into a format 

network interface for network 20. which is understand by a distributed transaction processing 

Distributed transaction processing system 56 provides system such as that "^^^^^^t^ 
data from database 28 to transaction clients 30, 32, 34 and system 52 (see also, FIG. 1). Gateways 213, 217 221 and 
36. Transaction clients 30, 32, 34 and 36 are coupled to 207 also transform data returned from the distributed trans- 
distributed transaction processing system 56 via interface 45 action processing system mto a formatted response which is 
3g returned to the requester. 

In the preferred embodiment, transaction gateway client WebViewC compiler 290 is used in conjunction with 
40 allows server 18 to interface with the transaction pro- specific Unisys gateway implementations, such as 
cessing system. When client 10, 12, 14 or 16 selects an ViewGate, TUXGate, or JGate. WebViewC compiler 290 
enterprise based service, the request is routed to server 18, 5 0 compiles open/OLTP view files generated on *e OLTP 
which in turn routes the request to transaction gateway client enterprise system to create WebTx view files (.wv) and 
40 Transaction gateway client 40 determines the requested HTML files (.html). WebViewC compiler 290 is a free- 
service and forwards the necessary information to distrib- standing component with no direct communication to any of 
uted transaction processing systems 54 and 56. Distributed the other components within the WebTx environment, 
transaction processing systems 54 and 56 process the request 55 Other WebTx Components include libraries 288 or the 
within database 28 according to the specified request (e.g., Software Development Kit (SDK) libraries, which provide 
select update, delete etc ... ). Distributed transaction framework and functions for building custom gateways. The 
processing systems 54 and 56 returns data and/or status SDK is specifically designed to allow customers to build 
information tool transaction gateway client 40, which in turn their own gateways. Another type of library present within 
formats the data in an appropriate manner for server 18. 60 the WebTx system are Java class libraries, which provide 
Server 18 then returns the information to requesting client class definitions for building JGate compatible applets. 
10, 12, 14 or 16. FIG. 3 is a block diagram showing the Microsoft NT 

FIG 2 is a block diagram of the preferred processing processing environment in which the present invention is 

environment of the present invention. A general WebTx used. The block diagram shown at 190 includes WebTx 

processing environment is shown at 180. WebTx is a Unisys 65 components utilized within a Microsoft NT environment and 

product. In general, WebTx is middleware in a client/server specific gateway implementations within Windows NT node 

computing environment which accepts requests from the 202. 
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SimpleGate Gateway 236 is a Unisys product which is to server 340 via interfaces 352, 354 and 356. HTML request 

specifically utilized as a test tool. It merely echoes a request. 350 is discussed in more detail in U.S. patent application 

The TUXGate Gateway 240 is a Unisys product which Ser. No. 08/622,099 filed Mar. 26, 1996 entitled: "Transac- 

provides generalized access to OLTP services through Tux- tion Service Independent Http Server to Transaction 

edo 266. Tuxedo 266 acts as the hub for distributed enter- 5 Gateway", which has been incorporated herein by reference, 

prise and Internet three-tier applications. Tuxedo 266 pro- Servef 34Q fa coup]ed t0 a num ber of gateways, corre- 

vides an open environment that supports a wide variety of sponding t0 Java applet 332, DCOM request 342 and HTML 

clients, databases, networks, legacy systems, and commu- request 350 Sefver 3^ fe t0 Java ga t e /Patbway 360 

nications options. The FileGate Gateway 244 is a Unisys yk mterface 358 Scrvcr 340 ^ t0 Java gate/ HTP 

product which works in conjunction with a specific OLTP 10 IC 3fig vU iaterface 366 Server 34/j is coupled to Java 

service to access textual files on the Unisys 2200 node. ga te/COM API 376 via interface 374. Since Java applet 332 

ViewGate 248 is a Unisys product which provides general- ^ QnQ type of provider of service requests, the gateways at 

ized access to OLTP services on the Unisys 2200 node (e.g. m m md m afC ovided to ^ icc thc requests from 

HTML output). JGate 252 is a Unisys product which pro- Jaya [et 332 

vides generalized Java tapplet acc^ss to OLTP services on the 15 ' ^ application running 

Unisys 2200 node. DGate gateway 256 is a Umsys product ^ M ^ DCQ ^ m ^^^ w ^ 

which provides generahzed DCOM access to OLTPservices from DCQM DCOM gateways are 

on the Unisys 2200 node. MapperGa te gateway 260 is a ^ r ed. ^ 34Q fc £ {q d ^ 384 via 

Unisys product which provides general^ accessto map. * ^ ^ ^ fe ^ ^ D e/HTp IC 390 

per applications within the Microsoft Windows NT Envi- 2Q v j a interface 388, Server 340 is coupled to Dgate/COM API 

ronment. Custom gateway 264 is a user customized gateway ^ ^ ^ Qf ^ ^ ^ ^ 

wherein a customer can build acustom gateway to interface ^ § ^ ^QOM request 342. 

custom applications to an OLTP enterprise application. 3 ^ Z 1 ... 

r™ /f . 1 1 j- 1- * Yet another type of requester is a web browser which 

HG. 4 b a block diagram showmg a prior art gateway provides requestsin Hyper-Text Markup Language (HTML) 

architecture. The prior art gateway architecture is found 2 s K . ™ M . • u „ „„ utui ,„„,.„,>. 

generally at 300. In the diagram at 300, a client 302 is f°™ a i: ™ e mm t 15 ? how ° » , ^ uest 

gtuciauy ai jwv. iu m , 350. These types of requests are handled by the following 

coupled to a listener 306 vi an interf ce pathway 304. ^ £ V.ewgale/Pathway 402 

Client 302 may be any of clients 10 12 1* o 16, « * > Viewgate/HTP IC 408 is coupled to server 

d.scussed in FIG. 1 Chen 302 may incorporate other Viewgate/COM API 414 is coupled to 

applications such as Internet Explorer, DCE and lracker. 30 . . . * A - , „, io ,„ n ,« ft im 

r ■ . t t . *„cn ;« server 340 via interface 412. Any of the gateways at 402, 

Listener 306 corresponds to web server system 50 shown in ,„ . ' ijttui ™,^r i«n 

t-t^ ^ t ■ . i/f^ • u r «• 408 or 414 may service requests from HImL request 35U. 

FIG. 1. Listener 306 may incorporate such applications as ™" ' ~* . ■ ™^ * 

Netscape Server, DCE Connector or Tracker Connector. ^ the P rior art data processing system shown in FIG. 5, 

Listener 306 includes web server 235, operating with web the gateways were customized for specific communications 

server extension 237 (see FIG. 2). The web server extension 35 P r °g rams > Realise each communications program typically 

is shown as WebTx DLL 310, which is coupled to listener utilizes * specific communications protocol, and thus 

306 via interface 308. Listener 306 is coupled to WebTx requires input parameters and services calls to be passed in 

gateway 314 via interface 312. WebTx gateway 314 may be * specific and unique format Ttec types of communica- 

any type of gateway, and may correspond to any of gateways tions programs are shown m FIG. 5, but it is understood that 

213, 217, 221 or 207, discussed in FIG. 2, or gateways 236, 40 manv olhers mav be commercia31 y available and within the 

240, 244, 248, 252, 256, 260 or 264, discussed in FIG. 3. of lhe P resent invention. 

WebTx tools 316 is discussed in FIG. 2 and FIG. 3. WebTx Pathway 364 is the Pathway program, which is commer- 
gateway 314 is coupled to end server 320 via interface 318. cially available frog BEA Corporation. HTP/IC 372 is the 
End server 320 may be any application on any systems such HTP/IC program commercially available from Unisys Cor- 
as OLTP or Mapper. 45 poration. COM API 380 is a third example of a communi- 

WebTx gateway 314 receives user requests from listener cations program. 

306, along with data, and packages the data into a specific In the prior art data processing system shown at 330, the 

format, then forwards the request and the data to end server gateway code to accept and process a specific kind of user 

320. End server 320 then processes the request, and may request is integrated with the code which interfaces with the 

send a result back to WebTx gateway 314. WebTx gateway 50 communication program. Thus, for a given request or type 

314 then provides the result to client 302 in a specified such as Java applet 332, a specific gateway must be created 

format. f° r cacn tvDC °f communications program that the requester 

FIG. 5 is a block diagram illustrating prior art gateways must access. Therefore, three Java gateways are required so 

incorporated within the data processing system of FIG. 1. Java applet 332 can have access to Pathway 364, HTP/IC 

The diagram is shown generally at 330. Java applet 332 is 55 372 and COM API 380. Therefore, JGate/Pathway 360 is 

coupled to server 340 via interfaces 334, 336, and 338. Java coupled to Pathway 364 via interface 362. JGate/HTP IC 

applet 332 is discussed in Application Ser. No. 09/164,759 368 is coupled to HTP/IC 372 via mterface 370, and 

filed Oct. 1, 1998, entitled: "A Common Gateway Which JGate/COM API 376 is coupled to COM API 380 via 

Allows Java Applets to Make Program Calls to OLTP interface 378. 

Applications Executing on an Enterprise Server", which has 60 The same is true for a request from DCOM request 342. 

been incorporated herein by reference. DCOM request 342 Thus, Dgate/Pathway 384 is coupled to pathway 364 via 

is coupled to server 340 via interfaces 344, 346 and 348. interface 386. Dgate/HTP IC 390 is coupled to HTP/IC 372 

DCOM request 342 is discussed in more detail in U.S. patent via interface 392. And Dgate/COM API 396 is coupled to 

application Ser. No. 09/164,932, filed Oct. 1, 1998, entitle: COM API 380 via interface 398. 

"A Multi Client User Customized DCOM Gateway for an 65 The same is also true for requests from HTML request 

OLTP Enterprise Server Application", which has been incor- 350. Viewgate/Pathway 402 is coupled to pathway 364 via 

porated herein by reference. HTML request 350 is coupled interface 404. Viewgate/HTP IC 408 is coupled to HTP/IC 



01/23/2004, EAST Version: 1.4.1 



US 6,212,546 Bl 

9 10 

372 via interface 410. And Viewgate/COM API 414 is The required functions of gateway 444 are now described 

coupled to COM API 380 via interface 416. in more detail. It is understood that while all specific 

Pathway 3164 is coupled to OLTP 2200 420 via interface references are to an NT platform, they are applicable to Unix 

418. HTP/IC 372 is coupled to OLTP 2200 420 via interface platforms as well. First, gateway 444 includes a connector 

422. And COM API 380 is coupled to OLTP 2200 420 via 5 header file, connect.h. This file contains definitions for the 

interface 424. three above functions called from the gateway. This file is 

Thus, in the prior art data processing system shown at located in the WebTx/I nclude directory. 

330, the number of gateways required on the server is Gateway 444 also includes the Initialize, ProcessRequest, 

equivalent to the number of requester types times the and ci eanup functions. Each of these functions calls a 

number of communications programs. Three requester types 10 corre sponding connector function within connector 448. The 

are illustrated, Java applet 332, DCOM request 342 and connector functionality is described in more detail below. 

Therefore the numLr of gateways required is equal to three ^ started. This function contains any code icquinx 1 to 

requesters times three communications programs, for 9 ^ mitiahze the gateway module. This may include establishing 

gateways total. TTiese 9 gateways are shown at 360, 368, 15 communications session, opening an application, or assign- 

376, 384, 390, 396, 402, 408, and 414. Thus the prior art ing any required local resources. The Initialize function 

system has a disadvantage of requiring a potentially large returns a "0" for a normal completion, or "-1" for an error 

number of different types of gateways to be resident on the condition. An error condition returned from the Initialize 

server. Furthermore, every time a new communications function causes the gateway to terminate. The prototype for 

program must be added, a new version of each gateway must 20 this function is "int Initialize(Gateinfo ♦Info);", 

be created. The Initialize function also loads the connector module 

FIG. 6 is a block diagram illustrating the gateway con- shown at connector 448, and initializes entry points to 

nector architecture of the present invention. The diagram is required connector functions. A function call contained in 

shown generally at 440. FIG. 6 is in many respects similar the WebTx tools library will load the connector DLL/SO so 

to FIG. 4, with the exception that gateway 444 and connector 25 that it is specified by a connector parameter in the gateway 

448 now replace WebTx gateway 314. configuration The DL17SO also contains the three connector 

Gateway 444 contains all software code associated with functions, Co Initialize, ConProcessRequest, and 

handling a specific requester type or client. All software ConCleanup, described below described below. The func- 

code associated with handling the communications program tion call to load the connector DLL/SO in the Windows NT 

to communicate with end server 320 is included within environment is "LoadDLLO", and ^ the Unix environment 

connector 448. Any gateway 444 can communicate with any is "LoadSOO"- 

connector 448 via interface 446. Gateway 444 is coupled to The Initialize function also makes the following function 

listener 306 via interface 442. Connector 448 is coupled to calls to the connector initialize function. In the Windows NT 

end server 320 via interface 450. 35 environment, the function call is "CoiiInitialize(Info)'\ In 

The new architecture shown at 440 splits the functions the Unix environment, the function call is 

previously handled by WebTx gateway 314 into the gateway "(*PtrConInitialize) (Info)." These function calls may also 

444 and connector 448 modules. Gateway 444 manages contain coded needed to initialize gateway 444, open 

communications to and from the user interface, shown as applications, or assign any required local resources, 

client 302, and also handles any formatting associated with 4Q The gateway mainf) function calls the ProcessRequest 

this communication. Gateway 444 may be any gateway, as function once for each web request routed to the gateway 

such as an OLTP gateway, Mapper gateway, Java gateway, process. This function contains code to parse input data (e.g. 

Dgate gateway or Viewgate gateway. the Gatelnfo structure described later). This function also 

Connector 448 prepares data received from the gateway, contains code to handle request data from the client. The 

to the format required by the application being used to talk 45 client may refer to the calling program, which may be a web 

to end server 320. These applications may include any browser, VB program, C++ program, or any other of a 

number of communication programs such as Pathway, HTP/ number of programs. The ProcessRequest function also 

IC or COM API (see FIG. 5). formats the request data for the call to the connector process 

End server 320 may be any application on any system request function. The ProcessRequest function also formats 

upon which service requests are sent and results are 50 response data received from the connector function, and 

returned. In the preferred embodiment, end server 320 is an returns the response data to the client. 

OLTP 2200 system. Connector 448 formats data received The ProcessRequest function returns a "0" for normal 

from end server 320 to a defined format, so that the data may completion, or a "-1" for an error condition. An error return 

be returned to gateway 444. from the ProcessRequest function causes the gateway to 

The WebTx environment provides a number of libraries of 55 terminate. The prototype for this function is "int Process- 

C functions to create the gateways. Gate.lib provides basic Request (Gatelnfo *Info);". 

gateway functions including the main() function. Tools.lib The ProcessRequest function makes the following func- 

provides convenient functions for manipulating input and tion call to connector 448. In the Windows NT environment, 

output data. ViewLib.lib provides input and output data the function call is "ConProcessRequest(Info,& Data,View, 

manipulation functions for gateways that intemperate with 60 SvcName,&Size)". In the Unix environment the function 

Open/OLTP applications. call is "(*PtrConProcessRequest)(Info,&Data,View, 

Three additional C functions are required. These are the SvcName,&Size)'\ 

Initialize function, the ProcessRequest function and the The gateway main() function also calls the Cleanup 

Cleanup function. The mainO function provided in the function when the gateway is terminating. This function 

gate.lib library calls these three functions during operation 65 contains any code required for a clean gateway termination, 

of the gateway. These functions will be described in more This function terminates a communication session, closes an 

detail below. application, or frees any assigned local resources. The 
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Cleanup function should return a "0" for a normal 
completion, or a "-1" for an error condition. An error return 
from Cleanup causes the gateway to terminate. This Cleanup 
function has the prototype of "int CleanUp(GateInfo * 
Info);". 

The Cleanup function further makes a function call to 
Connector 448 as follows. In the Windows NT environment, 
the function call is "ConCleanup (Info)". In the Unix 
environment, the function call is (*PtrConCleanup) (Info). 

Next the functionality of the Connector 448 module will 
be described. The three functions required by connector 448 
are Conlnitialize, ConProcessRequest, and ConCleanup. 
These functions are called from the gateway module (e.g. 
gateway 444, as discussed above. These functions serve the 
same purpose as the corresponding gateway functions, 
except they control the communication programs, instead of 
the user interface. 

The Conlnitialize function is called from gateway 444, 
via the Initialize function, when the gateway process has 
started. This function contains any code required to initialize 
the connector 448 module, such as establishing a commu- 
nications session, or allocating connectors for specific 
resources. The prototype for the Conlnitialize function is 
"int ConInitialize(GateInfo *Info);. 

The ConProcessRequest function is called from gateway 
444 via the ProcessRequest function, for each web request 
routed through the gateway process. The main purpose of 
this function is to handle any interaction with the commu- 
nications program. 

The following steps are performed by the ConProcessRe- 
quest function. First, the data received from the gateway 
module is formatted so that it can be used by the commu- 
nication program. This includes any actual data included in 
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name/value pairs that contain connector specific informa- 
tion. This information may be unique to a specific connector, 
or may be needed for multiple connectors. The difference 
between this information and the parameters in the function 
call is that this information is not needed for every connec- 
tor. Name/value pairs defined for this interface include: Type 
(e.g. view buffer type), Host, Port, Transaction and Build, 
This list is exemplary of information required by connector 
448, but it is understood that many more types of informa- 
tion may be utilized. 

The Char **Data parameter is both an input and output 
parameter. The buffer pointed to by this parameter contains 
the request data received from the user interface, and must 
be in the form of a view. The data in this buffer must be 
formatted as defined by an input view parameter. The 
memory for this buffer is allocated in gateway 444 using the 
function mallocQ. Gateway 444 frees this buffer using the 
function free(). 

Upon return from the function, this parameter is a pointer 
to a buffer that contains the response data. The response data 
20 in this buffer must be formatted as defined by the output 
view parameter. If the memory required for this buffer is 
greater than that of the input buffer, connector 448 must 
reallocate the memory using the function realloc(). It is 
important to reallocate the same buffer, so gateway 444 can 
25 free the memory, before exiting the ProcessRequest func- 
tion. 

The char *View parameter is both an input and output 
parameter, since the output view may be different from the 
input view. Upon input, this parameter is a pointer to the 
name of the view buffer that defines the request data. Upon 
output, this parameter is a pointer to the name of the view 
buffer that defines the response data. 

The char *ServiceName parameter is a pointer to the 
name of the application that will be called on end server 320. 



30 



any view, and any other parameters that are required by the 35 Jn ^ case of tfae 0pcn/0LTP system , this will be the name 



communication program. Examples of the parameters are 
"service name", "transaction", "ip address", etc. The next 
step performed by the ConProcessRequest function is to call 
the communication program. The next step performed by the 
ConProcessRequest function is to format the response data 40 
received from the communication program so that the data 
can be returned to gateway 444. The last step performed by 
the ConProcessRequest function is to return the formatted 
data to gateway 444 along with a return value of "0" if the 
function is completed without error. If the function encoun- 
ters an unrecoverable error, a value of is returned to 
gateway 444. 

The prototype for the ConProcessRequest function is "int 
ConProcessRequest(Gatelnfo *Info, char **Data, char 
*View, char *ServiceNarae, long *Size);" 

The ConCleanup function is called from gateway 444 via 
the Cleanup function when the gateway process is termi- 
nated. This function contains any code required to clean up 
the gateway, such is terminating a communication session, 
closing applications, or freeing any local resources assigned. 

The prototype for the ConCleanup function is "int 
ConCleanup(GateInfo *Info);*\ 

The interface between gateway 444 and connector 448 
includes the gateway functions Initialize, ProcessRequest, 
and Cleanup, and the connector functions Conlnitialize, 
ConProcessRequest and ConCleanup. The interface also 
includes the parameters passed to these functions. The 
function parameters are described below. 
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of the service. 

The long *Size parameter is both an input and an output 
parameter. Upon input, this is the size of the request data 
buffer. Upon output, this is the size of the response data 
buffer. 

FIG. 7 is a block diagram illustrating a preferred embodi- 
ment of the present invention, showing the gateway con- 
nector architecture incorporated within the data processing 
system of FIG. 1. The diagram at 480 illustrates the reduced 
number of software components required to couple the 
requesters at 332, 342 and 350, to the communications 
programs at 364, 372 and, 380. Java applet 332 is coupled 
to server 340 via interface 484. DCOM request 342 is 
coupled to server 340 via interface 490. HTML request 350 
is coupled to server 340 via interface 494. 

Server 340 is coupled to JGate gateway 498 via interface 
496. Server 340 is coupled to Dgate gateway 502 via 
interface 500. And server 340 is coupled to Viewgate 
gateway 506 via interface 504. 

JGate gateway 498 is coupled to pathway connector 510, 
HTP/IC connector 512 and COM API connector 514 via 
interface 508. Dgate gateway 502 is coupled to pathway 
connector 510, HTP/IC connector 512 and COM API con- 
nector 514 via interface 516. Viewgate gateway 506 is 
coupled to pathway connector 510, HTP/IC connector 512 
and COM API connector 514 via interface 518. 

Pathway connector 510 is coupled to pathway 364 via 
interface 520. HTP/IC connector 512 is coupled to HTP/IC 



Gatelnfo *Info is a parameter which is an informational 65 372 via interface 524. COM API connector 514 is coupled 
data structure used throughout all the gateways. An Info- to COM API 380 via interface 528. Pathway 364, HTP/IC 
>pTmp_Userl variable in this structure points to a buffer of 372, and COM API 380 are communications programs. 
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The prior art system shown in FIG. 5 required 9 gateways requests authentication. Finally, pass_thru_jndicates to the 

(shown at 360, 368, 376, 384, 390, 396, 402, 408, and 414) web server that even though control is passed to the gateway, 

, to interface the three requesters at 332, 342 and 350, with the request should be passed through to the next service 

the three communications programs at 364, 372, and 380. This is applicable only to the Netscape family of web 

With this prior art system, the number of gateways required 5 servers. When a value of req_autb or pass-thru is used, any 

is equal to the number of requesters (3), times the number of data that the gateway may have set up is ignored by the DLL 

communications programs (3), for a total of 9 required or SO and a j not sent to the browser. 

r ^ v 1 At line 570, Resp_ContentType is a required field that 

ga eways. contains the content type for the response. This field can 

In the preferred embodiment shown at 480, the number ot contain ASC[l tej£t only ( for example, "text/html"). The 

software code components is reduced to the number of 10 gateway must xi tn i s field prior to the first Transmit^ 

requesters (three requesters shown at 332, 342 and 350), ^ Une at $n indicates pTmp_Userl, and the line at 

plus the number of communications programs (three at 364, 5?4 ind i cates p Tmp_User2. These are pointers set aside for 

372 and 380), for a total of 6 required components. These 6 mc ga tewa y developer. They can point to data buffers that 

components are Java gate gateway 498, Dgate gateway 502, fa c gateway sends back to the web server through the 

Viewgate gateway 506, Pathway Connector 510, HTP/IC 15 TransmitO procedure. 

connector 512 and COM API connector 514. At ^ 57^ p Wr_CookieBuf, if the gateway sets 

It is understood that any of the gateways at 498, 502 and bWr_Cookies to a non-zero value prior to the first call to the 

506, may correspond to gateway 444 shown in FIG. 6. TransmitO function, then it must also set this to point to the 

Furthermore, any of the connectors at 510, 512 and 514, may character string containing the cookie to be sent back to the 

correspond to connector 448 shown in FIG. 6. The function browser. The gateway must allocate the space for the char- 

and operation of the gateways and connectors have been aCter string. The first call to the TransmitO taction will 

described above in FIG. 6. copy the cookie data to a different location, so the gateway 

FIG. 8 is a diagram showing the informational data can deallocate the space for the character string if desired, 

structure used in the present invention. The data structure is 2$ The gateway should not modify the value of pWr_ 

shown generally at 550. CookieBuf if it is not sending a cookie. 

The gateway functions discussed above in FIG. 6 use a FIG. 9 is a diagram showing the data structure used to 

specific data structure for input data. This data structure also reference data variables provided by a web server. The data 

provides access to environment variables, and allows the use structure is shown generally at 590. The pointers in this 

of cookies. Therefore the data structure has three parts, 30 structure reference the standard common gateway interface 

which are Gate Info, ReqVars and Cookielnfo. Gatelnfo is data variables provided by the web server. It is understood 

described below, while ReqVars is described in FIG. 9, and that this data stricture is exemplary, as the actual contents of 

Cookielnfo is described in FIG. 10. each variable can be varied by the web server. If the web 

With Gatelnfo, each time mainO calls a custom function, server provides no data for a particular variable, the vari- 

a single parameter (Info) passes to the function. The Info 35 able's pointer contains a null. The gateway handles all data 

parameter is pointer to an information structure having the referenced by these pointers as read only data. WebTx does 

format shown at 550. not look at mese pointers or their data on the return to the 

At line 552 of the format at 550, arg is the number of web servers extension (the associated DLL or SO), 

arguments passed to the gateway at execution time. FIG. 10 is a diagram showing the data structure used to 

At line 554, **argv is an array of pointers to the argu- 40 reference cookie data received by the server from the client 

nts assed to the gateway browser. The pointers in this structure point to the cookie 

men P^ e J- daU received b y the server from the client browser. Upon 

At line 556 pGate.in^ data » >, t pointer tcv data submitted / m ^ ^ 

from an HTML form using the POST method. ^ ^ ^ 

At line 58, dwGate„in_data_ len is the number of bytes ^ ^ ^ at m indicates * pCo okie [20], which is an array 

of data in the Gate_in_data buffer. Qf l0 data> !f me gateway sets the bWr_ 

At Une 560, pVars is a structure which contains pointers Cookies variable to a nonzero value, and sets pWr_ 

to standard common gateway interface request variables. CookieBuf to point to cookie data prior to the first call to the 

The ReqVars structure is discussed in FIG. 9. TransmitO faction, WebTx sends one cookie to the client 

At line 562, pCookies is the third part of the gateway data 50 browse for the current session. There is no guarantee that the 

structure. The pCookies structure contains pointers to a client browser will accept the cookie. Thus, on input to the 

defined number of possible cookies used for both input and gateway, cookies that are expected may or may not be 

output. The Cookielnfo structure definition provides further present. The Wr_CookieBuf should have the format of 

details, and is discussed in FIG. 10. "NAME«value; expires«=date; path=path; domain=domain_ 

At lines 564 and 566, with b\Vr_C6okies, if the gateway 55 name; secure". An example of this format is "PRODUCT** 

sets this integer variable to a non-zero value, on output the WebTx; path=/foo; expires -Tuesday, Mar. 25, 1997 

associated program extension (DLL or SO) sends a cookie 23:00:00 GMT". 

to the client browser of the current session. To send the FIGS. 11 A, 11B and 11C are a flow diagram showing an 
cookie, the gateway must set this flag before it calls the first exemplary method of the present invention. The flow dia- 
TransmitO function. The gateway must also set pWr__ go gram communicates la request from a requester to an end 
CookieBuf to point to the cookie data. server, wherein the requester is coupled to a server, and a 
At line 668, Resp__Control and is a field which contains number of communications programs are coupled to an end 
a value to indicate how to process the response. Current server. A first module is coupled to the server, and each one 
values are as follows. First, send_response tells the gateway of a number of second modules are coupled to a correspond- 
to send a response. This is the normal case in which HTML 65 ing one of the number of communications programs. The 
data is sent to the browser. Here send_response is the end server processes the request, and returns a result in 
default value. Second, req_auth indicates that the gateway response to the request. 
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The flow diagram is shown generally at 620. The flow 
diagram is entered at element 622, wherein control is passed 
to element 624 via interface 626. Element 624 sends a 
request from the requester to the first module. Control is then 
passed to element 628 via interface 630. Element 628 calls 
a first initialize function to initialize the first module and 
load a one of the number of second modules corresponding 
to a one of the number of communications programs to 
communicate with the end server. Element 628 may further 
comprise the first initialize function establishing a commu- 
nications session with the second module. Element 628 may 
further comprise the first initialize function opening a num- 
ber of application programs resident on the server. Element 
628 may further comprise the first initialize function assign- 
ing memory resources on the server. Control is then passed 
to element 632 via interface 634. Element 632 calls a second 
initialize function to initialize the one of the number of 
second modules Element 632 may further comprise the 
second initialize function establishing a communications 
session with the one of the number of communication 
modules. Element 632 may further comprise the second 20 
initialize function opening a number of application programs 
resident on the server. Element 632 may further comprise the 
second initialize function assigning memory resources on 
the server. Control is then passed to element 636 via 
interface 638. Element 636 calls a first process request 25 
function from the first module to format the request received 
from the requester so that the request can be sent to the one 
of the number of second modules. Control is then passed to 
element 640 via interface 642. Element 640 calls a second 
process request function from the first process request 30 
function to send the request to the one of the number of 
second modules, the second process request function for- 
matting the request received from the first module so that the 
one of the number of second modules can send the request 
to the one of the number of communication programs. 
Control is then passed to element 644 via interface 646. 
Element 644 sends the request to the one of the number of 
communication programs so that the end server can process 
the request. Control is then passed to element 648 via 
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Having thus described the preferred embodiments of the 
present invention, those of skill in the art will readily 
appreciate that the teachings found herein may be applied to 
yet other embodiments within the scope of the claims hereto 
attached. 

What is claimed is: 

1. A data Processing system wherein a number of request- 
ers are coupled to a server and a number of communications 
programs are coupled to an end server, the end server 
processing a number of service requests from the number of 
requesters and returning a number of results in response to 
the number of service requests, comprising: 

a. an interface coupled to the server for linking each one 
of the number of requesters with each one of the 
number of communications programs so that each one 
of the number of requesters can submit at least one of 
the number of service requests through each one of the 
communications programs and receive at least one of 
the number of results in response to said at least one of 
the number of service requests 

b. a number of first modules wherein each one of said 
number of first modules corresponds to one of the 
number of requesters; and 

c. a number of second modules wherein each one of said 
number of second modules corresponds to one of the 
number of communications programs, each said one of 
said number of first modules able to interface with 
every said one of said number of second modules by 
passing a number of function calls between each said 
one of said number of first modules and every said one 
of said number of second modules so that each one of 
the number of requesters can submit at least one of the 
number of service requests through each one of the 
number of communications programs and receive at 
least one of the number of results in response to said at 
least one of the number of service requests. 

2. The data processing system according to claim 1 
wherein one of said number of function calls is a first 
initialize function, said first initialize function initializing 



interface 650. Element 648 processes the request. Control is 40 said one of said number of first modules and loading said 



then passed to element 652 via interface 654. Element 652 
returns the result in response to the request from the end 
server to the one of the number of communication programs 
so that the one of the number of second modules can receive 
the result. Control is then passed to element 656 via interface 45 
658. Element 656 sends the result from the one of the 
number of communication programs to the one of the 
number of second modules. Control is then passed to ele- 
ment 660 via interface 662. Element 660 formats the result 
by the second process request function so that the result can 50 
be returned to the first module. Control is then passed to 
element 664 via interface 666. Element 664 sends the result 
from the one of the number of second modules to the first 



one of said number of second modules corresponding to said 
one of the number of communications programs, said first 
initialize function making a second initialize function call to 
initialize said one of said number of second modules. 

3. The data processing system according to claim 2 
wherein said first initialize function initializes said one of 
said number of first modules by establishing a communica- 
tions session with said one of said number of said second 
modules. 

4. The data processing system according to claim 2 
wherein said first initialize function initializes said one of 
said number of first modules by opening a number of 
application programs resident on the server. 

5. The data processing system according to claim 2 



module. Control is then passed to element 668 via interface 

670. Element 668 formats the result by the first process 55 wherein said first initialize function initializes said one of 

request function so that the result can be returned to the said number of first modules by assigning memory resources 

requester. Control is then passed to element 672 via interface on the server. 

674. Element 672 sends the result from the first module to 6. The data processing system according claim 2 wherein 

the requester. Control is then passed to element 676 via said second initialize function initializes said one of said 

interface 678. Element 676 calls a first cleanup function 60 number of second modules. 

once the requester is removed, wherein the first cleanup 7. The data processing system according to claim 6 

function terminates the first module. Control is then passed wherein said second initialize function initializes said one of 

to element 680 via interface 682. Element 680 calls a second said number of second modules by establishing a commu- 

cleanup function from the first cleanup function, wherein the nications session with said one of the number of commu- 

second cleanup function terminates the one of the number of 65 nication programs. 

second modules. Control is then passed to element 684 via 8. The data processing system according to claim 6 

interface 686, where the algorithm is exited. wherein said second initialize function initializes said one of 
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said number of second modules by opening a number of a. first module means coupled to the server, and 

application programs resident on the server. b. second module means coupled to the number of com- 

9. The data processing system according to claim 6 munications programs, said first module means com- 
wherein said second initialize function initializes said one of pleting a number of function calls so that said first 
said number of second modules by assigning memory 5 module means can communicate a one of the number of 
resources on said server. service requests received from a one of the number of 

10. The data processing system according to claim 1 requesters to the second module means and return a one 
wherein one of said number of function calls is a first of tne num t»er of results received from the second 
process request function, said first process request function module means to said one of the number of requesters 
being called by said one of said number of first modules to %Q m6 Mid mo dule means can communicate said 
format said one of the number of service requests received Qne of me numbef of requests to a one of the 
from said one of the number of requesters for a second Qumber of communicalions pr0 grams and return the 
process request function call to said one of said number of from 0Qe f ^ numbef of com . 
second modules to send said one of the number of service „ . , mD ™ 
requests to said one of said number of second modules, said ^TT* pr ° gramS 10 ^ ** ^ ™T' 77 
fSt process request function formatting said one of the " 23. The data processmg system accordmg o claim 22 
number of results received from said one of said number of wherein one of said number of foncUon ^ * 1 * B| 
second modules in response to said one of the number of initialize function, said first initialize function initializing 
service requests and reUirning said one of the number of said first module means and loading said second module 
results to said one of the number of requesters. means corresponding to said one of the number of commu- 

11 . The data processing system according to claim 10 20 nications programs, said first initialize function making a 
wherein said second process request function formats said second initialize function call to initialize said second mod- 
one of the number of service requests received from said one ule means. 

of said number of first modules so that said one of said 24. The data processing system according to claim 23 

number of second modules can send said service request to wherein said first initialize function initializes said first 

said one of the number of communication programs, said 25 module means by establishing a communications session 

second process request function formatting said one of the with said second module means. 

number of results received from the one of said number of 25. The data processing system according to claim 23 

communications programs in response to said one of the wherein said first initialize function initializes said first 

number of service requests so that said one of the number of module means by opening a number of application programs 

results can be returned to said one of said number of first 30 resident on the server. 

modules. 26. The data processing system according to claim 23 

12. The data processing system according to claim 10 wherein said first initialize function initializes said first 
wherein one of said number of function calls is a first module means by assigning memory resources on the server, 
cleanup function, said first cleanup function terminating said 27. The data processing system according claim 23 
one of said number of first modules, said first cleanup 35 wherein said second initialize function initializes said sec- 
function calling a second cleanup function. ond module means. 

13. The data processing system according to claim 12 28. The data processing system according to claim 27 
wherein said second cleanup function terminates said one of wherein said second initialize function initializes said sec- 
said number of second modules. ond module means by establishing a communications ses- 

14. The data processing system according to claim 1 40 sion with said one of the number of communications pro- 
wherein said number of first modules are a number of grams. 

gateway modules. 29. The data processing system according to claim 27 

15. The data processing system according to claim 1 wherein said second initialize function initializes said see- 
wherein said number of second modules are a number of ond module means by opening a number of application 
connector modules. 45 programs resident on the server. 

16. The data processing system according to claim 2 30. The data processing system according to claim 27 
wherein said first initialize function is an Initialize function. wherein said second initialize function initializes said sec- 

17. The data processing system according to claim 6 ond first module means by assigning memory resources on 
wherein said second initialize function is a Conlnitialize the server. 

function. 50 31. The data processing system according to claim 22 

18. The data processing system according to claim 10 wherein one of said number of function calls is a first 
wherein said first process request function is a ProcessRe- process request function, said first process request function 
quest function. being called by said first module means to format said one 

19. The data Processing system according to claim 11 of the number of service requests received from said one of 
wherein said second process request function is a ConProc- 55 the number of requesters for a second process request 
essRequest function. function call to said second module means to send said one 

20. The data processing system according to claim 12 of the number of service requests to said second module 
wherein said first cleanup function is a Cleanup function. means, said first process request function formatting said 

21. The data processing system according to claim 13 one of the number of results received from said second 
wherein said second cleanup function is a ConCleanup 60 module means in response to said one of the number of 
faction. service requests and returning said one of the number of 

22. A data Processing system wherein a number of results to said one of the number of requesters, 
requesters are coupled to a server and a number of commu- 32. The data processing system according to claim 31 
nications programs are coupled to an end server, the end wherein said second process request function formats said 
server processing a number of service requests from the 65 one of the number of service requests received from said first 
number of requesters and returning a number of results in module means so that said second module means can send 
response to the number of service requests, comprising: said one of the number of service requests to said one of the 
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number of communication programs, said second process 
request function formatting said one of the number of results 
received from the one of said number of communications 
programs in response to said one of the number of service 
requests so that said one of the number of results can be 5 
returned to said first module means. 

33. The data processing system according to claim 31 
wherein one of said number of function calls is a first 
cleanup function, said first cleanup function terminating said 
first module means, said first cleanup function calling a 10 
second cleanup function. 

34. The data processing system according to claim 33 
wherein said second cleanup function terminates said second 
module means. 

35. A method of communicating a request from a 
requester to an end server wherein the requester is coupled 
to a server and a number of communications programs are 
coupled to an end server, a first module being coupled to the 
server and each one of a number of second modules being 
coupled to a corresponding one of the number of commu- 
nications programs, the end server processing the request 
and returning a result in response to the request, comprising 
the steps of: 

a. calling a first initialize function to initialize the first 
module and load a one of the number of second 
modules corresponding to a one of the number of 
communications programs to communicate with the 
end server; 

b. calling a second initialize function to initialize the one 
of the number of second modules; 

c. sending a request from the requester to the first module; 

d. calling a first process request function from the first 
module to format the request received from the 
requester so that the request can be sent to said one of 35 
the number of second modules; 

e. calling a second process request function from said first 
process request function to send the request to said one 
of the number of second modules, said second process 
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h. returning the result in response to the request from the 
end server to said one of the number of communication 
programs so that said one of the number of second 
modules can receive the result; 

i. sending the result from said one of the number of 
communication programs to said one of the number of 
second modules; 

j, formatting the result by said second process request 
function so that the result can be returned to the first 
module; 

k. sensing the result from said one of the number of 

second modules to the first module; 
1. formatting the result by said first process request 

function so that the result can be returned to the 

requester; 

m. sending the result from the first module to the 
requester; 

n. calling a first cleanup function once the requester has 

been removed, said first cleanup function terminating 

the first module; and 
o. calling a second cleanup function from the first cleanup 

function, said second cleanup function terminating said 

one of the number of second modules. 

36. The method according to claim 35 wherein step (b) 
further comprises the step of said first initialize function 
establishing a communications session with the second 
module. 

37. The method according to claim 35 wherein step (b) 
further comprises the step of said first initialize function 
opening a number of application programs resident on the 
server. 

38. The method according to claim 35 wherein step (b) 
further comprises the step of said first initialize function 
assigning memory resources on the server. 

39. The method according to claim 35 wherein step (c) 
further comprises the step of said second initialize function 
establishing a communications session with said one of the 
number of communication modules. 

40. The method according to claim 35 wherein step (c) 



request function formatting the request received from 40 fufther the step of said ^cond initialize function 



said first module so that said one of the number of 
second modules can send the request to said one of the 
number of communication programs; 

f. sending the request to said one of the number of 
communication programs so that the end server can 
process the request; 

g. processing the request; 
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opening a number of application programs resident on the 
server. 

41. The method according to claim 35 wherein step (c) 
further comprises the step of said second initialize function 
assigning memory resources on the server. 
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